home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1264.txt < prev    next >
Text File  |  1997-04-01  |  17KB  |  451 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Hinden
  8. Request for Comments: 1264                                           BBN
  9.                                                             October 1991
  10.  
  11.  
  12.                     Internet Engineering Task Force
  13.            Internet Routing Protocol Standardization Criteria
  14.  
  15. Status of this Memo
  16.  
  17.    This informational RFC presents procedures for creating and
  18.    documenting Internet standards on routing protocols.  These
  19.    procedures have been established by the Internet Activities Board
  20.    (IAB) in consultation with the Internet Engineering Steering Group
  21.    (IESG).  Distribution of this memo is unlimited.
  22.  
  23. 1.0  Introduction
  24.  
  25.    The IAB and the IESG have evolved a three-stage Internet
  26.    standardization process.  This process is explained in the "IAB
  27.    Official Protocol Standards", published as an RFC several times a
  28.    year (the current version is RFC 1250).
  29.  
  30.    In brief, the three stages of Internet standardization are Proposed
  31.    (which requires a well written, openly reviewed specification), Draft
  32.    (which requires Proposed status, multiple implementations and some
  33.    operational experience), and full Internet Standard (which requires
  34.    Draft status and more extensive operational experience).  The IAB and
  35.    IESG are currently developing a more detailed explanation of the
  36.    process, which will be available as an RFC.
  37.  
  38.    The purpose of this document is to provide more specific guidance for
  39.    the advancement of routing protocols.  All levels of the
  40.    standardization process are covered.
  41.  
  42.    There are currently two types of routing protocol in the Internet.
  43.    These are Interior Gateway Protocols (IGP) sometimes called Intra-
  44.    Domain Routing Protocols and Exterior Gateway Protocols (EGP)
  45.    sometimes called Inter-Domain Routing Protocols.  This document uses
  46.    the terms IGP and EGP.
  47.  
  48. 2.0 Motivation
  49.  
  50.    The motivation for these requirements two-fold.  The first is to
  51.    reduce the risk that there will be serious technical problems with a
  52.    routing protocol after it reaches Draft Standard.  The second is to
  53.    insure that the new routing protocol will support the continued
  54.    growth of the Internet.
  55.  
  56.  
  57.  
  58. Hinden                                                          [Page 1]
  59.  
  60. RFC 1264               Routing Protocol Criteria            October 1991
  61.  
  62.  
  63.    Routing protocols are complex, widely distributed, real-time
  64.    algorithms.  They are difficult to implement and to test.  Even
  65.    though a protocol may work in one environment with one
  66.    implementation, that does not ensure that it will work in a different
  67.    environment with multiple vendors.  A routing protocol may work well
  68.    within a range of topologies and number of networks and routers, but
  69.    may fail when an unforeseen limit is reached.  The result is that
  70.    even with considerable operational experience, it is hard to
  71.    guarantee that the protocol is mature enough for widespread
  72.    deployment.
  73.  
  74.    The Internet is currently growing at an exponential rate.  Routing
  75.    protocols and the management of internet addressing are key elements
  76.    in the successful operation the Internet.  It is important that new
  77.    routing protocols be designed to support this rapid growth.
  78.  
  79. 3.0 General Requirements
  80.  
  81.    1) Documents specifying the Protocol and its Usage.  This may be
  82.       one or more documents.  The specifications for the routing
  83.       protocol must be well written such that independent,
  84.       interoperable implementations can be developed solely based on
  85.       the specification.  For example, it should be possible to
  86.       develop an interoperable implementation without consulting the
  87.       original developers of the routing protocol.
  88.  
  89.    2) A Management Information Base (MIB) must be written for the
  90.       protocol.  Routing protocols, like all other internet protocols,
  91.       need a MIB defined so they can be remotely managed.
  92.  
  93.    3) A security architecture of the protocol must be defined.  The
  94.       security architecture must include mechanisms for authenticating
  95.       routing messages and may include other forms of protection.
  96.  
  97.    4) Generally, a number of interoperable implementations must
  98.       exist.  At least two must be written independently.
  99.  
  100.    5) There must be evidence that all features of the protocol have
  101.       been tested, running between at least two implementations.  This
  102.       must include that all of the security features have been
  103.       demonstrated to operate, and that the mechanisms defined in the
  104.       protocol actually provide the intended protection.
  105.  
  106.    6) There must be operational experience with the routing
  107.       protocol.  The level of operational experience required is
  108.       dependent on which level of standardization is requested.  All
  109.       significant features of the protocol must be exercised.  In the
  110.       case of an Interior Gateway Protocol (IGP), both interior and
  111.  
  112.  
  113.  
  114. Hinden                                                          [Page 2]
  115.  
  116. RFC 1264               Routing Protocol Criteria            October 1991
  117.  
  118.  
  119.       exterior routes must be carried (unless another mechanism is
  120.       provided for the exterior routes).  In the case of a Exterior
  121.       Gateway Protocol (EGP), it must carry the full complement of
  122.       exterior routes.
  123.  
  124.    7) Two reports must be submitted to the IESG via the Routing Area
  125.       Director.  The first report must document how requirements 1)
  126.       through 6) of this document have been satisfied.  It must
  127.       include:
  128.  
  129.       - Implementation experience.
  130.  
  131.       - Reference to the MIB for the protocol.
  132.  
  133.       - Description of the authentication mechanisms in the protocol.
  134.  
  135.       - List of implementations including origin of code.
  136.  
  137.       - Test scenarios and test results showing that all features of the
  138.         protocols have been tested.
  139.  
  140.       - Description of operational experience.  This must include
  141.         topology, environment, time and duration, implementations
  142.         involved, and overall results and conclusions gained from the
  143.         operational experience.
  144.  
  145.    The second report must summarize the key features of the protocol and
  146.    analyze how the protocol will perform and scale in the Internet.  The
  147.    intent of this requirement is to understand the boundary conditions
  148.    of the routing protocol.  The new routing protocol must be compared
  149.    with the existing routing protocols (e.g., RIP, EGP, etc.) as
  150.    appropriate.  The report should answer several questions:
  151.  
  152.       - What are the key features and algorithms of the protocol?
  153.  
  154.       - How much link bandwidth, router memory and router CPU cycles
  155.         does the protocol consume under normal conditions?
  156.  
  157.       - For these metrics, how does the usage scale as the routing
  158.         environment grows?  This should include topologies at least an
  159.         order of magnitude larger than the current environment.
  160.  
  161.       - What are the limits of the protocol for these metrics? (I.e.,
  162.         when will the routing protocol break?)
  163.  
  164.       - For what environments is the protocol well suited, and for what
  165.         is it not suitable?
  166.  
  167.  
  168.  
  169.  
  170. Hinden                                                          [Page 3]
  171.  
  172. RFC 1264               Routing Protocol Criteria            October 1991
  173.  
  174.  
  175.    The IESG will forward to the IAB its recommendation for advancement
  176.    of the new routing protocol based on its evaluation of protocol
  177.    specifications and these reports.
  178.  
  179. 4.0 Requirements for Proposed Standard
  180.  
  181.    1) Documents specifying the Protocol and its Usage.  The
  182.       specification for the routing protocol must be well written such
  183.       that independent, interoperable implementations can be developed
  184.       solely based on the specification.  For example, it should be
  185.       possible to develop an interoperable implementation without
  186.       consulting the original developers of the routing protocol.
  187.  
  188.    2) A Management Information Base (MIB) must be written for the
  189.       protocol.  The MIB does not need to submitted for Proposed
  190.       Standard at the same time as the routing protocol, but must be
  191.       at least an Internet Draft.
  192.  
  193.    3) The security architecture of the protocol must be set forth
  194.       explicitly.  The security architecture must include mechanisms for
  195.       authenticating routing messages and may include other forms of
  196.       protection.
  197.  
  198.    4) One or more implementations must exist.
  199.  
  200.    5) There must be evidence that the major features of the protocol
  201.       have been tested.
  202.  
  203.    6) No operational experience is required for the routing protocol
  204.       at this stage in the standardization process.
  205.  
  206.    7) A report must be submitted to the IESG via the Routing Area
  207.       Director.  The report must document the key features of the
  208.       protocol and describe how requirements 1) through 5) have been
  209.       satisfied.  It must include:
  210.  
  211.       - What are the key features and algorithms of the protocol?
  212.  
  213.       - For what environments is the protocol well suited, and for what
  214.         is it not suitable?
  215.  
  216.       - Description of the authentication mechanisms in the protocol.
  217.  
  218.       - Reference to the MIB for the protocol.
  219.  
  220.       - Implementation experience.
  221.  
  222.       - List of implementations including origin of code.
  223.  
  224.  
  225.  
  226. Hinden                                                          [Page 4]
  227.  
  228. RFC 1264               Routing Protocol Criteria            October 1991
  229.  
  230.  
  231.       - Test scenarios and test results showing that the major features
  232.         of the protocols have been tested.
  233.  
  234.    The IESG will forward to the IAB its recommendation for advancement
  235.    of the new routing protocol to Proposed Standard based on its
  236.    evaluation of protocol specifications and this reports.
  237.  
  238. 5.0 Requirements for Draft Standard
  239.  
  240.    1) Revisions to the Protocol and Usage documents showing changes and
  241.       clarifications made based on experience gained in the time
  242.       between when the protocol was made a Proposed Standard and it
  243.       being submitted for Draft Standard.  The revised documents should
  244.       include a section summarizing the changes made.
  245.  
  246.    2) The Management Information Base (MIB) must be at the Proposed
  247.       Standard level of standardization.
  248.  
  249.    3) Two or more interoperable implementations must exist.  At least
  250.       two must be written independently.
  251.  
  252.    4) There must be evidence that all features of the protocol have
  253.       been tested, running between at least two implementations.  This
  254.       must include that all of the security features have been
  255.       demonstrated to operate, and that the mechanisms defined in the
  256.       protocol actually provide the intended protection.
  257.  
  258.    5) There must be significant operational experience.  This must
  259.       include running in a moderate number routers configured in a
  260.       moderately complex topology, and must be part of the operational
  261.       Internet.  All significant features of the protocol must be
  262.       exercised.  In the case of an Interior Gateway Protocol (IGP),
  263.       both interior and exterior routes must be carried (unless another
  264.       mechanism is provided for the exterior routes).  In the case of
  265.       a Exterior Gateway Protocol (EGP), it must carry the full
  266.       complement of exterior routes.
  267.  
  268.    6) Two reports must be submitted to the IESG via the Routing Area
  269.       Director.  The first report must document how requirements 1)
  270.       through 5) of this document have been satisfied.  It must include:
  271.  
  272.       - Reference to the MIB for the protocol.
  273.  
  274.       - Description of the authentication mechanisms in the protocol.
  275.  
  276.       - List of implementations including origin of code.
  277.  
  278.       - Implementation experience.
  279.  
  280.  
  281.  
  282. Hinden                                                          [Page 5]
  283.  
  284. RFC 1264               Routing Protocol Criteria            October 1991
  285.  
  286.  
  287.       - Test scenarios and test results showing that all features of the
  288.         protocols have been tested.
  289.  
  290.       - Description of operational experience.  This must include
  291.         topology, environment, time and duration, implementations
  292.         involved, and overall results and conclusions gained from the
  293.         operational experience.
  294.  
  295.    The second report must summarize the key features of the protocol and
  296.    analyze how the protocol will perform and scale in the Internet.  The
  297.    intent of this requirement is to understand the boundary conditions
  298.    of the routing protocol.  The new routing protocol must be compared
  299.    with the existing routing protocols (e.g., RIP, EGP, etc.) as
  300.    appropriate.  The report should answer several questions:
  301.  
  302.       - What are the key features and algorithms of the protocol?
  303.  
  304.       - How much link bandwidth, router memory and router CPU cycles
  305.         does the protocol consume under normal conditions?
  306.  
  307.       - For these metrics, how does the usage scale as the routing
  308.         environment grows?  This should include topologies at least an
  309.         order of magnitude larger than the current environment.
  310.  
  311.       - What are the limits of the protocol for these metrics? (I.e.,
  312.         when will the routing protocol break?)
  313.  
  314.       - For what environments is the protocol well suited, and for what
  315.         is it not suitable?
  316.  
  317.    The IESG will forward to the IAB its recommendation for advancement
  318.    of the new routing protocol to Draft Standard based on its evaluation
  319.    of protocol specifications and these reports.
  320.  
  321. 6.0 Requirements for Standard
  322.  
  323.    1) Revisions to the Protocol and Usage documents showing changes and
  324.       clarifications made based on experience gained in the time between
  325.       when the protocol was made a Draft Standard and it being submitted
  326.       for Standard.  The changes should be to clarify the protocol
  327.       or provide guidance in its implementation.  No significant changes
  328.       can be made to the protocol at this stage.  The revised documents
  329.       should include a section summarizing the changes made.
  330.  
  331.    2) The Management Information Base (MIB) must be submitted for
  332.       Standard at the same time as the routing protocol.
  333.  
  334.    3) Three or more interoperable implementations must exist.  At least
  335.  
  336.  
  337.  
  338. Hinden                                                          [Page 6]
  339.  
  340. RFC 1264               Routing Protocol Criteria            October 1991
  341.  
  342.  
  343.       two must be written independently.
  344.  
  345.    4) There must be evidence that all features of the protocol have been
  346.       tested, running between at least two independently written
  347.       implementations.  This must include that all of the security
  348.       features have been demonstrated to operate, and that the mechanisms
  349.       defined in the protocol actually provide the intended protection.
  350.  
  351.    5) There must be significant operational experience.  This must
  352.       include running in a large number routers configured in a complex
  353.       topology, and must be part of the operational Internet.  The
  354.       operational experience must include multi-vendor operation.  All
  355.       significant features of the protocol must be exercised.  In the
  356.       case of an Interior Gateway Protocol (IGP), both interior and
  357.       exterior routes must be carried (unless another mechanism is
  358.       provided for the exterior routes).  In the case of a Exterior
  359.       Gateway Protocol (EGP), it must carry the full complement of
  360.       exterior routes.
  361.  
  362.    6) Two reports must be submitted to the IESG via the Routing Area
  363.       Director.  The first report must document how requirements 1)
  364.       through 5) of this document have been satisfied.  It must include:
  365.  
  366.       - Reference to the MIB for the protocol.
  367.  
  368.       - Description of the authentication mechanisms in the protocol.
  369.  
  370.       - List of implementations including origin of code.
  371.  
  372.       - Implementation experience.
  373.  
  374.       - Test scenarios and test results showing that all features of the
  375.         protocols have been tested.
  376.  
  377.       - Description of operational experience.  This must include
  378.         topology, environment, time and duration, implementations
  379.         involved, and overall results and conclusions gained from the
  380.         operational experience.
  381.  
  382.    The second report should be a revision to the report prepared when
  383.    the protocol was submitted for Draft Standard.  It must describe the
  384.    additional knowledge and understanding gained in the time between
  385.    when the protocol was made a Draft standard and when it was submitted
  386.    for Standard.
  387.  
  388.    The IESG will forward to the IAB its recommendation for advancement
  389.    of the new routing protocol to Standard based on its evaluation of
  390.    protocol specifications and these reports.
  391.  
  392.  
  393.  
  394. Hinden                                                          [Page 7]
  395.  
  396. RFC 1264               Routing Protocol Criteria            October 1991
  397.  
  398.  
  399. Security Considerations
  400.  
  401.    Security issues are not discussed in this memo.
  402.  
  403. Author's Address
  404.  
  405.    Robert M. Hinden
  406.    Bolt Beranek and Newman, Inc.
  407.    50 Moulton Street
  408.    Cambridge, MA 02138
  409.  
  410.    Phone: (617) 873-3757
  411.  
  412.    EMail: hinden@bbn.com
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Hinden                                                          [Page 8]
  451.